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EMERGENCY SERVICES FOR PACKET NETWORKS 

Field of the Invention 

[0001] The present invention relates to connmunications, and in particular 
5 to ensuring emergency calls supported in part over a packet network are 
properly handled, even during overload conditions. 

Background of the Invention 

[0002] Providing emergency services, especially in overload conditions, is 

10 challenging since service providers have to ensure that emergency calls are 
established regardless of other non-emergency calls. In the public switched 
telephone network (PSTN), there are mechanisms to identify calls made from 
and to special locations which involve providing emergency services. These 
locations include 91 1 call centers, police departments, hospitals, fire stations, 

15 and various government agencies. Generally, excessive network resources 
are reserved to ensure completion of emergency calls, and call setup 
requests for requesting the establishment of a call are given processing 
priority when they are within the various switching nodes within the PSTN. 
Accordingly, the PSTN currently has the ability to properly prioritize and 

20 handle emergency calls. 

[0003] With respect to packet-based communications, packet networks are 
increasingly being used to deploy voice-based communications using various 
types of voice over packet (VoP) calls. Unfortunately, the openness of 
packet-based architectures has presented a cjiallenge for properly handling 

25 emergency calls. Although there are numerous packet-based devices which 
can filter and route calls, this is no overriding solution for ensuring emergency 
calls are properly processed and prioritized over non-emergency calls. 
Further, there is a need to ensure that emergency calls can be properly 
handled in overload conditions as well as ensure that the system is not 

30 abused by malicious users who improperly identify their calls as emergency 
calls or initiate malicious attacks, such as denial of service attacks. 
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Summary of the Invention 

[0004] The present invention provides a technique for facilitating 
emergency services via packet networks. Emergency service providers will 
implement emergency proxies to ensure that proper call setup requests for 
5 emergency services are forwarded to the appropriate entities, even if the 
network or those entities are in overload conditions. The emergency proxies 
may authenticate and filter call setup requests to ensure that only proper call 
setup requests are forwarded to help prevent abusive, malicious or 
unauthorized use of emergency services. The emergency proxy may operate 

10 solely in a packet network, as well as at the interface between a packet 
network and a circuit-switched network to assist in call setup requests 
originating from either the packet network or the circuit-switched network. 
[0005] Those skilled in the art will appreciate the scope of the present 
invention and realize additional aspects thereof after reading the following 

15 detailed description of the preferred embodiments in association with the 
accompanying drawing figures. 

Brief Description of the Drawing Figures 

[0006] The accompanying drawing figures incorporated in and forming a 
20 part of this specification illustrate several aspects of the invention, and 

together with the description serve to explain the principles of the invention. 

[0007] Figure 1 is a block representation of a communication environment 

according to one embodiment of the present invention. 

[0008] Figure 2 is a communication flow diagram providing an exemplary 
25 scenario for implementing emergency services according to one embodiment 

of the present invention. 

[0009] Figure 3 is a block representation^of a communication environment 
according a second embodiment of the present invention. 
[0010] Figure 4 is a communication flow diagram providing an exemplary 
30 scenario for implementing emergency services according to a second 
embodiment of the present invention. 

[0011] Figures 5 is a communication flow diagram providing an exemplary 
scenario for implementing emergency services according to a third 
embodiment of the present invention. 
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[0012] Figure 6 is a block representation of an emergency proxy according 
to one embodiment of tlie present invention. 

Detailed Description of the Preferred Embodiments 
5 [001 3] The embodiments set forth below represent the necessary 
information to enable those skilled in the art to practice the invention and 
illustrate the best mode of practicing the invention. Upon reading the 
following description in light of the accompanying drawing figures, those 
skilled in the art will understand the concepts of the invention and will 

10 recognize applications of these concepts not particularly addressed herein. It 
should be understood that these concepts and applications fall within the 
scope of the disclosure and the accompanying claims. 
[0014] With reference to Figure 1 , a communication environment 10 is 
provided wherein an originating element 12 is a communication device 

15 attempting to establish a call to a terminating element 14 via a packet network 
16. For the present invention, the term "call" includes traditional voice-based 
calls, as well as media sessions, which include any type of data, audio, voice, 
or video based packet sessions. In the illustrated embodiment, the originating 
element 12 is supported by an emergency proxy 18, and the terminating 

20 element 14 may be supported by a proxy 20 in traditional fashion, wherein the 
emergency proxy 18 and the proxy 20 will act as liaisons for call or session 
establishment messages involving the respective devices. 
[0015] Accordingly, the originating element 12 will send a call setup 
request configured to initiate a call between the originating element 12 and 

25 the terminating element 14. In traditional proxy fashion, the call setup request 
is received by the emergency proxy 18, which will determine if the call setup 
request meets the emergency criteria of an emergency call setup request. 
The emergency criteria are preferably provisioned by emergency services 
providers, such that these providers can effectively control how call setup 

30 requests are processed. If the emergency criteria are met, the emergency 
proxy 18 will modify the call setup request in a defined manner and forward 
the call setup request across the packet network 16 to initiate the call. The 
call setup request may be forwarded to the terminating element 14 directly or 
indirectly via the proxy 20. In one embodiment, the proxy 20 may be 
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configured to analyze the call setup request to ensure that the call setup 
request is properly configured by the emergency proxy 18 as a condition to 
sending the call setup request to the terminating element 14. As such, the 
emergency proxy 18 and perhaps the proxy 20 are configured to process call 
5 setup requests from the originating element 12 to ensure that only authorized 
call setup requests result in emergency calls, by effectively filtering call setup 
requests actually delivered to the terminating element 14 or supporting 
entities. 

[0016] Preferably, the emergency proxy 18 will authenticate the call setup 

10 request to ensure that the originating element 12 can initiate a request for an 
emergency call, as well as limit the call setup requests sent toward the 
terminating element 14 to those that are authenticated. The emergency proxy 
18 may add an additional field, referred to in general as an emergency header 
field, to the call setup request. The emergency header field may include 

15 additional information that uniquely identifies the level of emergency, and 
information identifying the call, such as caller identification, to and from 
addresses, and the like. For additional security to avoid malicious or 
unauthorized use of emergency services, the emergency proxy 18 may 
encrypt the emergency header field information in a manner allowing the 

20 proxy 20, terminating element 14, or other supporting entity to be able to 

decrypt information when attempting to establish an emergency call. Notably, 
private or public key encryption techniques may be employed that are well 
known in the art. Authentication of call setup requests or an originating 
element 12 sending the call setup request may be based on the identity of the 

25 originating element 12, a user of the originating element 12, or authentication 
information provided when generating the call setup request. The emergency 
proxy 18 will be provisioned with the necessary information to facilitate 
authentication of the various originating elements 12 that are served by the 
emergency proxy 18. 

30 [0017] Notably, the emergency proxy 18 may provide multiple levels of 
prioritization for various types of call setup requests and may filter call setup 
requests according to these priority levels and network conditions, as well as 
include indicia indicating an assigned prioritization level in each call setup 
request. The receiving proxy 20, terminating element 14, any other 
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intermediate proxy or supporting entity, if any, will process the incoming call 
setup request according to the assigned prioritization level, network 
conditions, and the like. 

[0018] In a preferred embodiment, at least a portion of the communication 
5 sessions established between the originating element 12 and the terminating 
element 14 are facilitated using the Session Initiation Protocol (SIP). The 
specification for SIP is provided in the Internet Engineering Task Force's 
Request for Comments (RFC) 3261: Session Initiation Protocol Internet Draft, 
which is incorporated herein by reference in its entirety. In general, SIP is 

10 used to establish media sessions between any number of endpoints, such as 
the originating and terminating elements 12, 14. Typically, these endpoints 
may support any number or combination of data, audio, and voice media 
sessions, depending on the configuration of the device. A SIP endpoint is 
capable of running an application, typically referred to as a user agent (UA), 

15 which is capable of facilitating media sessions using SIP. 

[0019] In certain embodiments, user agents may register their ability to 
establish sessions with a SIP proxy, such as the emergency proxy 18 or proxy 
20, by sending REGISTER messages to the SIP proxy. The REGISTER 
message informs the SIP proxy of the SIP universal, resource locator (URL) 

20 that identifies the user agent to the SIP network. The REGISTER message 
also contains information about how to reach specific user agents over the 
SIP network, typically by providing the Internet Protocol (IP) address and port 
that the user agent will use for SIP sessions. When a user agent wants to 
establish a session with another user agent, the user agent initiating the 

25 session may send an INVITE message to the SIP proxy and specify the target 
user agent in the TO header of the INVITE message. Identification of the user 
agent takes the form of a SIP URL. The SIP proxy will use the SIP URL in the 
TO header of the message to determine if the targeted user agent is 
registered with the SIP proxy. Generally the user name is unique within the 

30 name space of the specified domain. 

[0020] If the targeted user agent has registered with the SIP proxy, the SIP 
proxy will forward the INVITE message directly to the targeted user agent. 
The targeted user agent will respond with a 200 OK message, and a session 
between the respective user agents will be established as per the message 
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exchange required in the SIP specification. IVIedia capabilities are passed 
between the two user agents of the respective endpoints as parameters 
embedded within the session setup messages, such as the INVITE, 200 OK, 
and acknowledgement (ACK) messages. Media capabilities may be 
5 exchanged in other messages, such as the SIP INFO message. Media 
capabilities are typically described using the Session Description Protocol 
(SDP). Once respective endpoints are in an active session with each other 
and have determined each other's capabilities, the specified media content 
may be exchanged during an appropriate media session. 

1 0 [0021] According to the Internet Engineering Task Force's RFC 3261 , a 
user agent is an application that contains both a user agent client and a user 
agent server. A user agent client generally refers to a client application that 
initiates SIP requests, wherein a user agent server is an application that 
contacts the user when a SIP request is received, and returns a response on 

15 behalf of the user. Typically, the response accepts, rejects, or redirects the 
received request. 

[0022] With reference to Figure 2, a communication flow diagram is 
provided from an exemplary scenario wherein one or more originating 
elements 12 are sending call setup requests in the form of INVITE messages 

20 to initiate a call via a SIP session with one or more terminating elements 14. 
Assume that the terminating elements 14 provide emergency services and 
only emergency calls should be handled by the terminating elements 14. 
Accordingly, the emergency proxy 18 will only forward incoming call setup 
requests, in the form of SIP INVITE messages, which meet the necessary 

25 criteria for being emergency call setup requests to the terminating elements 
14. Initially, assume that an INVITE message intended to establish a call with 
a terminating element 14 is sent from the originating element 12 (step 100). 
Further assume that the originating element 12 is either unauthorized to 
establish an emergency call or that the INVITE message would not meet the 

30 necessary criteria for establishing an emergency call. As such, the 

emergency proxy 18 will determine if the INVITE message meets the defined 
emergency criteria (step 102), and since this INVITE message would not meet 
the emergency criteria, the emergency proxy 18 will ignore the INVITE 
message and not forward the INVITE message toward the terminating 
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element 14 (step 104). The emergency proxy 18 may be configured to 
provide a response indicative of not forwarding the INVITE message back to 
the originating element 12 (not shown) 

[0023] Next, assume that an appropriate originating element 12 sends a 
5 proper INVITE message for Initiating an emergency call to the terminating 
element 14. The emergency proxy 18 will receive the INVITE message (step 
106), and determine if the INVITE message meets the emergency criteria 
(step 108). Since the INVITE message meets the emergency criteria, the 
emergency proxy 18 generates an emergency header field (step 110) and 

10 adds the emergency header field to the INVITE message (step 112). The 
INVITE message is then fonA/arded toward the terminating element 14 (step 
1 14). Since the terminating element 14 is associated with a proxy 20, the 
proxy 20 will receive the INVITE message on behalf of the terminating 
element 14 and may be configured to determine if the proper emergency 

1 5 header field is present (step 1 1 6). If the proper emergency header field is 
present, the INVITE message is fonA/arded to the terminating element 14 
wherein the session supporting the call can be established with the originating 
element 12 (step 118). 

[0024] In the event that the proxy 20 receives an INVITE message without 
20 the proper emergency header field from any device (step 120), the proxy 20 
will determine if the proper emergency header field is present (step 122), and 
since the field is not present, may ignore the INVITE message (step 124). As 
such, the emergency proxy 18 provides the proper authentication and filtering 
for call setup requests to ensure that terminating elements 14 providing 
25 emergency services are only sent appropriate call setup requests. Further, 
the proxy 20 supporting the terminating elements 14 may provide further 
authentication and filtering to ensure that the terminating element 14 only 
receives appropriate call setup requests. Again, further security may be 
provided using encryption and decryption techniques between the emergency 
30 proxy 18 and the proxy 20. The proxy 20 and the emergency proxy 18 may 
also monitor work conditions to help provide filtering for the various call setup 
requests, as well as prioritize the call setup requests based on any available 
criteria. 
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[0025] Turning now to Figure 3, the concepts of the present invention 
readily extend to circuit-switched networks 22, such as the PSTN, wherein an 
emergency proxy 18 is implemented in or in association with a gateway 
facilitating an interface between the packet network 16 and the circuit- 
5 switched network 22. In such a configuration, the emergency proxy 18 can 
control circuit-switched call setup requests as well as packet-based call setup 
requests originating from the circuit-switched network 22 and the packet 
network 16, respectively. 

[0026] An exemplary communication call flow for filtering call setup 

10 requests originating from the packet network 16 and intended for a device on 
the circuit-switched network 22 is provided in Figure 4. In this example, an 
initial INVITE message, which does not meet the emergency criteria, is sent 
from the originating element 12 to establish an emergency call with a device 
in the circuit-switched network 22. The emergency proxy 18 will receive the 

15 INVITE message (step 200) and determine if the INVITE message meets the 
emergency criteria (step 202). Since the emergency criteria are not met, the 
emergency proxy 18 will ignore the INVITE message (step 204) and perhaps 
report the same back to the originating element 12 (not shown). 
[0027] When an appropriate INVITE message is sent from an originating 

20 element 12 (step 206), the emergency proxy 18 will receive the INVITE 

message and determine if the INVITE message meets the emergency criteria 
(step 208). Since the emergency criteria is met, the emergency proxy 1 8 may 
generate one or more emergency parameters (step 210) and create a call 
setup request with the emergency parameter (step 212), wherein the call 

25 setup request is configured to initiate a call in the circuit-switched network 22. 
An exemplary call setup request for the PSTN is an intelligent network Initial 
Address Message (lAM). As such, the emergency proxy 18 will send a call 
setup request to the appropriate entity in the circuit-switched network 22 to 
initiate the emergency call (step 214). The call setup request will include the 

30 emergency parameters to assist the entities in the circuit-switched network 22 
in determining whether the call setup request is appropriate. The emergency 
parameters may be carried in signaling information elements as specified by 
the appropriate standards that define the Multi-Level Precedence and 
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Preemption Supplementary Service, which is well known and provides for 
prioritizing voice traffic. 

[0028] Turning now to Figure 5, assume that entities in the circuit-switched 
network 22 are attempting to establish emergency calls with a terminating 
5 element 14 in the packet network 16. Accordingly, call setup requests in the 
form of lAMs are received by the emergency proxy 18 from the circuit- 
switched network 22 (step 300). Assume that the first call setup request 
would not meet the emergency criteria for establishing an emergency call with 
the terminating element 14, and as such, the emergency proxy 18 will 

10 determine that the call setup request does not meet the emergency criteria 
(step 302) and will ignore the call setup request (step 304). Again, the call 
setup request may be an lAM, which may include various parameters to assist 
in determining whether the emergency criteria are met. 
[0029] Assume that another call setup request, which would meet the 

1 5 emergency criteria, is received by the emergency proxy 18 from the circuit- 
switched network 22 (step 306). The emergency proxy 18 will determine if the 
call setup request meets the emergency criteria (step 308) and since it does 
meet the emergency criteria, the emergency proxy 18 will generate an 
emergency header field (step 310) and create an INVITE message intended 

20 for the terminating element 14 with the emergency header field (step 312). 
The emergency proxy 18 will then send the INVITE message with the 
emergency header field toward the terminating element 14. The proxy 20 will 
receive the INVITE message (step 314) and may be configured to determine if 
a proper emergency header field is present (step 316). If the proper 

25 emergency header field is present, the INVITE message is fonA/arded to the 
terminating element 14 to establish the emergency call (step 318). Notably, 
the session between the emergency proxy 18 or associated gateway and the 
terminating element 14 may be a SIP session, wherein the connection within 
the circuit-switched network 22 will be a circuit-switched connection. As 

30 described above, the proxy 20 may receive INVITE messages without the 
proper emergency header field (step 320), and then determine if the proper 
emergency header is present (step 322). When the proper emergency 
header field is not present, the INVITE message may be ignored (step 324). 
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[0030] With any of the above embodiments, the emergency proxy 18 will 
preferably be configured to ensure that a proper call setup request is always 
forwarded to or towards the terminating element 14, even in overload 
conditions. Further, in non-overload conditions, the emergency proxy 18 as 
5 well as the proxy 20 may be configured to fon/vard all of select INVITE 

messages or forward them based on desired criteria, yet prioritize emergency 
requests as well as eliminate non-emergency requests during overload 
conditions. 

[0031] With reference to Figure 6, a high level block diagram of an 
1 0 emergency proxy or device capable of performing the function of an 

emergency proxy is illustrated. The emergency proxy 18 will typically include 
a control system 24 having memory 26 for storing the necessary software 28 
to facilitate the above functionality. The control system 24 will also be 
associated with one or more communication interfaces 30 for communicating 
15 over the packet network 16, and perhaps the circuit-switched network 22, as 
necessary. 

[0032] Those skilled in the art will recognize improvements and 
modifications to the preferred embodiments of the present invention. All such 
improvements and modifications are considered within the scope of the 
20 concepts disclosed herein and the claims that follow. 



